-
Notifications
You must be signed in to change notification settings - Fork 86
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix early-data test #132
Fix early-data test #132
Conversation
Would you like to open it on the ci by the way? |
Sure, I added another command to run that test. |
The test seems to fail on windows, maybe there is a problem with openssl on windows ci machine. we can disable it on windows ci. |
.github/workflows/CI.yml
Outdated
run: cargo test --all | ||
run: | | ||
cargo test --all | ||
cargo test -p tokio-rustls --features early-data |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we can add --test test_0rtt
so that it doesn't need to repeat the test
I ran a modified version of the test on both Linux and Windows, and it seems that this might be due to cross-platform differences in OpenSSL, but I can't rule out an issue in rustls yet. In both cases, I do see "hello" sent in application data. On Linux, the server sends two session tickets (nonce zero before the client's days and nonce one after the client's data), but I don't see any session tickets on Windows. In both cases, I see a client-to-server close notify alert, and I see a FIN from the client. However, I do not see a FIN from the server on Windows, only Linux. Even more suspicious, OpenSSL's key log is missing CLIENT_TRAFFIC_SECRET_0, compared to the key log file from rustls. The connection works enough to get data through in both directions, but there seems to be something wrong with higher-level connection state machines. With a base set of changes, I see that This suggests one side or the other may be forgetting to read from a pipe or socket when it should, or forgetting to wake a future appropriately. (I added a missing wake to a Pending control flow in |
I have some changes in a branch at https://github.com/divergentdave/tokio-tls/tree/early-data-debugging, and I think the results strongly suggest an I/O handling bug in
Here, we see that OpenSSL intended to write 0x880 bytes, but only wrote about half of it at first. Immediately after the test wrote a newline to OpenSSL's stdin, it finished sending out this write of handshake data. Looking at the packet capture, the first packet sent after the first delay, corresponding to the first network event after the stdin write, is a new session ticket message sent from the server to the client. Thus, I think we can rule out misbehavior on the part of tokio-rustls (for example, failing to drain a TCP connection buffer) because the connection gets unstuck without any interaction with the Rust side (ignoring the stdin write itself). On the other hand, running |
This is necessary to work around an issue that only appears on Windows.
3d6ab03
to
5241396
Compare
Thank you for your meticulous research! |
The domain name this test uses was not updated when the test certificate was replaced previously. FWIW, this test isn't covered by CI, since it's behind an off-by-default feature flag.